1. Field of the Invention
This invention relates to techniques for a flow admission control framework for a developed Internet. In particular, it relates to a method and system for building an admission control framework that keeps the stateless property of the Internet, allows statistical multiplexing gains, and handles admission control of both TCP and UDP flows.
2. Description of Related Art
Internet Protocol (“IP”) networks are traditionally designed to support best-effort services, with no guarantees for reliable and timely delivery of packets. With the migration of what has become the ubiquitous transport network to data as well as real-time applications like voice and video, the Internet needs to provide quality of service (“QoS”) as predictably as conventional circuit switching networks. Although some QoS capabilities in an isolated environment have been demonstrated, providing end-to-end QoS at a large scale across the Internet remains an unsolved problem.
Many data-plane techniques, such as scheduling and classification, have been invented to reduce delay and delay jitters. But data plane components are not enough to solve the problem. If the total amount of data entering the Internet exceeds the amount the network can sustain, no methods can guarantee the QoS. The general consensus is that, besides data plane components, flow admission control (“FAC”) must be implemented to deliver hard QoS in the Internet.
One of the key issues in the design of the QoS Internet is to decide between a stateful and a stateless network. Differentiated Services (“DiffServ”) is a stateless approach. DiffServ keeps per-flow information only at the edge of a network, but it uses class-based scheduling and buffering priorities in the core of the network. Without FAC, DiffServ can only provide “soft” QoS (probabilistic QoS) guarantees where one class of traffic receives relatively better service than other classes. Some measurement-based FAC schemes have been proposed to enable access routers to send out ping-like probing packets to measure the end-to-end delay, or even available bandwidth of the path before admitting a flow. It is doubtful, however, that hard QoS can be supported with this approach due to its inherent limitations—delay is not useful and the accuracy for bandwidth measurement is not high enough to support hard QoS guarantee.
Bandwidth broker (BB) is a stateful approach. In practice, a BB often morphs into a soft switch. The Resource Admission Control Subsystem (“RACS”) of the Next Generation Network (“NGN”) architecture is such an example. It stores the entire topology of the network, collects session-layer signaling messages (such as Session Initiation Protocol “SIP” and H.323), and updates the link state database according to the bandwidth used for each flow. Because the RACS stores the topology and tracks the bandwidth utilization of each link under its control, it does not need to exchange link state updates with routers in the network. There are many problems with this approach, some of which are discussed below:                1. It is too slow for TCP flows° FAC. Sending setup packets to the RACS does not work in this case as the flow admission decision must be made immediately upon the arrival of a TCP flow's first packet.        2. The RACS does not communicate with routers about a link's current utilization status; thus, the RACS needs to perform strict resource reservation for each flow. This means that RACS can not easily reap statistical multiplexing gains of a packet network.        3. If a discrepancy between the database of the RACS and the real bandwidth consumed exists, either the bandwidth will be lost or the network will be over utilized and will experience congestion.        4. A centralized device creates a single-point failure problem.        5. Inter-operability can be a problem as different domains have different ways to implement the bandwidth broker.        
Flow aware routers are another stateful approach. A flow-aware router stores the state information of each flow and performs bandwidth reservation (based on the RSVP and the InteServ model) and admission control accordingly. When a new flow arrives, an entry in the state table is created. If we use a soft-state approach, the entry will be removed after a certain period of time. Detecting a new TCP flow can be easily conducted at the transport layer (SYN=1, ACK=1); however, detecting a new UDP flow is not as easy. In some references in the field, this is done by checking whether a UDP packet's four-tuple address (source IP, source port, destination IP, destination port) is in the state table 101, shown in FIG. 1. If not, a new entry will be created in the state table 101.
This approach transforms the Internet from a stateless into a stateful network. Cost and scalability are some obvious problems. A large amount of fast memory is required for storing the states of millions of flows. The link rate has now reached 40 Gbps (OC768). It is not clear if storing states of each flow is even feasible for such high-rate routers. But economical issues aside, this approach suffers from another serious problem: detecting UDP flows at the transport layer makes routers vulnerable to denial-of-service (DOS) attacks. Hackers can just send in as many UDP datagrams as possible. Because each flow contains one packet, the router will be swamped with the task of setting up and tearing down the UDP single-packet flows. The networks can be brought down easily accordingly.
The above discussion shows that performing FAC for UDP flows at the transport layer make the network vulnerable to DoS attacks. In this invention, we propose a new FAC architecture where UDP flows' FAC will be done at the session layer. Flows are established through setup packets. When a link along the path of an incoming setup packet is congested, a router will block the setup packets to prevent new flows from being added to the network. Thus path setup packets also serve the function of probing the congestion status of the network. However, FAC is not as simple as it appears. There are several factors contributing to the difficulties of FAC in the Internet. One is that FAC needs to be support both TCP flows and UDP flows. While TCP flows can be identified at the transport layer, UDP flows can only be identified in session layer protocols, such as SIP and H.323. This presents a difficult problem. Referring to FIG. 3, the signaling path, the solid lines linking Client A 325 to Edge Router 310 to Edge Router 335 to Signaling Server C 315, and linking Client B to Edge Router 301 to Edge Router 335, is different from the data path, the broken lines linking from Edge Router 310 to Edge Router 305 to Edge Router 301. Thus the status of the signaling path may not reflect the congestion status of the data path. The probing performed by setup packets can not guarantee the QoS of the data paths of UDP flows.